Day 23:把併發控制手段實際裝進訂單服務 結尾講得很直白:Semaphore 與 withTimeout 這兩道防護都裝上了,但真正動到庫存數量本身的那個操...
Day 22:收斂進一個具名專案,訂單服務實戰整合版啟動 結尾說得很坦白:骨架能動,不代表它已經具備任何高併發防護。OrderService.getOrderD...
Day 21:小結,高併發控制的工具箱總覽,準備進實戰 把併發深化期七天累積的節流、逾時取消、背壓、連線池搭配與 k6 量測方法論收攏成一份完整的工具箱,也提前...
Day 20:實測結果解讀,協程贏在哪裡、代價又是什麼 結尾說得很直接,七天下來累積了節流、逾時取消、背壓、連線池搭配,再加上一套完整的效能量測方法論,五樣工具...
Day 19:幫協程模型量身打造一場效能比較 把該準備的都準備好了:公平比較的規則講清楚了,k6 定案為全系列壓測工具,模擬促銷流量爬升的測試情境也設計完成。昨...
Day 18:協程遇上 R2DBC 連線池,小心連線被偷偷耗盡 結尾留下一個問題:協程模型相對於 Thread-per-Request 模型,實際上能帶來多少效...
Day 17:背壓是什麼,生產太快時該怎麼踩煞車 結尾留下一個問題:背壓機制確實能避免資料無限制堆積,但消費端實際處理這些資料時,往往需要依賴某項數量有限的資源...
Day 16:逾時與取消,讓卡住的協程別拖垮整個系統 結尾留下一個問題:withTimeout 解決的是某個協程異常卡住太久的狀況,但如果問題根本不是卡住,而是...
Day 14:小結:三種技術選型的判斷依據,MVC、WebFlux 各用在哪 結尾留下一個尖銳的問題:即使底層是 WebFlux 搭配 R2DBC 這種從骨子裡...
Day 13:協程搭配訊息佇列與外部 API 呼叫的常見模式 結尾把問題攤開來了:這幾天累積的技術選型各自看起來都理解了,但實務上該根據什麼判斷依據去選擇,還沒...
Day 11:WebFlux 是什麼,協程與反應式模型的分工 停在一個尚未回答的風險上:即使應用程式用 WebFlux 搭配協程,整條請求處理鏈路理論上可以是非...
在上一篇文章 Day 10:在 Spring MVC 裡寫 suspend function,能動但有代價 最後留下一個問題:如果限制的源頭是底層容器骨架,有沒...
Day 09:小結:四個核心觀念如何在一次請求中協同運作 結尾留下一個還沒正面回答的問題:協程終究要活在一個真實的 Spring Boot 應用程式裡,它要接...
Day 08:Coroutine Context 與例外處理,協程出錯了誰負責 結尾把 Coroutine Scope、Structured Concurren...
《Day 07:Dispatchers,協程實際跑在哪條執行緒上》 結尾留下一個問題:Dispatcher 其實只是協程隨身攜帶的其中一項設定,那協程執行時還帶...
Day 06:Structured Concurrency,為什麼協程不能亂長亂放 結尾留下一個問題:確立了協程之間誰該對誰負責之後,這些協程實際上到底是在哪一...
Day 05:Coroutine Scope,協程住在哪裡、活多久 結尾留下一個問題:同一個 Scope 裡如果同時養著好幾個協程,其中一個先執行完,或者其中一...
《Day 04:小結:把 Thread 模型與協程模型放在一起比一次》 結尾留下一個疑問:訂單查詢與扣庫存服務裡,有些步驟適合同時發起,一旦一個請求裡需要同時或...
《Day 03:第一個 suspend function,協程到底暫停了什麼》結尾留下一個疑問:一個函式暫停了,那一整串呼叫呢。今天先不回答這個疑問,而是往回看...
《Day 02:Thread-per-Request 模型的極限,搞懂你原本在用什麼》 結尾停在一個問句上:如果執行緒能在等待的時候先被借走,去處理別的請求,等...
《Day 01:為什麼高併發後端需要協程,從一個會卡住的 API 說起》結尾留下一個看似簡單卻很少人真正答得出來的問題:你的 Spring Boot 應用程式收...
昨天我們深入剖析了 Timeout 設定與容量規劃的數學公式,證明了盲目放寬 Timeout 只會讓連線池乾涸。 今天,我們要將壓力測試的視角從PUT上傳轉向l...
昨天在 Day 00 的地圖裡,我們先按下不表那個會卡住的 API,只留下一句預告:今天要把它攤開來看清楚,它到底卡在哪裡。現在就從這個畫面開始。 開場,一個會...
如果你是一個習慣寫 Java 後端的工程師,大概對這個畫面不陌生。系統上線初期流量還小,每個 API 都反應飛快,Controller 收到請求,Service...
昨天我們成功在 JMeter 上傳併發測試中,證明了前面寫的保護api的功能將 3 秒超時引發的錯誤率從 53% 降至 0%,並透過 Grafana 發現真正的...
我們從一開始的三高指標與同步/非同步引擎對決,一路升級到分散式環境下的防禦機制(Semaphore 背壓限流、Double-Check 、uploadId 冪等...
在前幾天的文章中,我們在微服務中建構了多道盾牌,從透過headObject 探針解決網路超時問題的 Double-Check Pattern,實作 Idempo...
昨天我們完成了 Double-Check Pattern 的實作,當 putObject 發生 timeout 時,後端不再直接回傳失敗,而是使用 headOb...
在前兩篇中,我們在本地開發環境裡,利用了 simulateScenario 在代碼內部模擬超時,驗證了自我修復確實可以起死回生,手把手完成了微服務的三層防禦盾牌...
昨天我們說明了網路世界最殘酷的一面。當微服務呼叫 AWS S3 上傳檔案時,如果發生 TimeoutException時不能直接斷言上傳一定失敗,也有可能是上傳...